BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / gt_power / qcvt105.zip / ADDENDUM.NET next >

Wrap

Text File | 1989-10-26 | 57KB | 1,274 lines

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PLEASE note these new phone numbers. THANK YOU! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Voice: (602) 285-9914 Modem: (602) 285-1146 Netmail: 009/000 (713) 772-2090 001/003 - more - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ADDENDUM TO NETMAIL DOCUMENTATION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright 1989 P&M Software Co. October 26, 1989 All rights reserved. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netmail Version 300 10-26-89 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. MDRIV now supports baud rates in excess of 19,200. So all you guys 'n gals can try 38,400 baud. This program must now be installed to use. The installation procedure is quite simple, the first time the program is run, it will prompt you for the required information: name, S/N and GT key. The program should not be renamed until successful installation has been done. Also, you should have the program in the GTPATH directory and it should be made the default directory when the installation is done. Also, when a connection is made between MDRIV's 047 and above, the GTNET.LOG will show you that S/N and first 9 characters of the registered owners name. This will help us track the source of unauthorized usage. 2. The netmail programs now support file inclusion. That is you can break your routing file down and build them back. For example, my ROUTING.BBS looks like this: ; ; MAIN NETMAIL ROUTING FILE FOR 001/033 ; $ PURSUIT.RTE ; $ OUTBOUND.RTE ; $ WINDOWS.RTE ; $ ROUTE.RTE $ ECHO.033 END ; $ DISTRIB.RTE ; ECHOMAIL HOURS 0100-2459 Each line that begins with a '$' names another file to be included into the current ROUTING.BBS. This makes it very easy to track each functional section of the routing file. File inclusion is completely optional. 3. (Q)uick Bags! (Q)uick Bags are replacements for the old E bags. You know the bags that are named like this: E0954001.E00. Now we will have a replacement for the E bags, named like the E bags, but with the first character of the filename equal to Q, like this: Q0954001.E00. (Q)uick bags are 20-50% smaller than regular E bags created with PKARC, and maybe even smaller than ZIPped E bags, since these archivers do not handle small files like messages well. To create a (Q)uick bag we use our own squeeze program, called NMSQ (which must be placed into your GTPATH directory). Also, the WORDLIST file must be present. This is a dictionary of words used in a pre-compression process. There are two new command line arguments, /Q and /QO, for MBAG. These arguments enable the creation of (Q)uick bags. MDIST will continue to be able to unpack both types of bags. When you specify the /Q option on the command line of MBAG, (Q)uick bags will be generated for all conferences that are sponsored on your system, in addition to the regular E bags. You may examine the results to see the efficiency (or lack thereof) of the new procedure. The /QO option will cause MBAG to generate (Q)uick bags ONLY. If you require E bags later, the QCVT program can be used to create E bags from your (Q)uick bags. The QCVT program is described below. Selective generation of (Q)uick bags is possible by adding a Q to the line in the MESSAGE DISTRIBUTION section for the indicated conferences. Like this: MESSAGE DISTRIBUTION E01/009,10 -> D:\BETA_ECO , ;GT_Beta_Echo E01/011,10,Q -> D:\TEST_ECO , ;Q_Test_Echo END In this example, E01/009 will have only E bags generated and E01/011 will have both (Q)uick and E bags generated. Of course, this assumes that no /Q is given on the MBAG command line. This syntax is only useful for conferences that you sponsor. Selective inclusion of (Q)uick bags in G bags may be accomplished by a similar mechanism in the BAG CONSOLIDATION section. Like this: BAG CONSOLIDATION 001/032,Z E00/001,955 E01/009,955 E01/010,955 003/000 E01/009,955 E01/010,955 009/000,ZQ E00/001,955 E00/005,955 END In the above example, nodes 001/032 and 003/000 will get normal E bags put into their G bags, but node 009/000 will receive (Q)uick bags if they are available. If (Q)uick bags are not available, then 009/000 will receive regular E bags. Notice, as well, that 001/032 and 009/000 receive ZIPped G bags. 4. The QCVT program is being made freely available to everyone. It will perform three different tasks: A. Take E bags and make (Q)uick bags from them. Option /Q. B. Take (Q)uick bags and make E bags from them. Option /E. C. Take (Q)uick bags and make M files (in \MAILWORK). No option. Here are some command line examples: QCVT [filespec] [option] If not specified, the filspec will default to \MAILOUT\*.* If not specified, the option will default to C above, which breaks down (Q)uick bags into their component M files. QCVT /E Means to search \MAILOUT for all (Q)uick bags and generate E bags, if they do not already exist. QCVT /Q Means to search \MAILOUT for all E bags and generate (Q)uick bags, if they do not already exist. QCVT q0955001.e01 Take this (Q)uick bag and break it down into M message files in the \MAILWORK directory. 5. A new file, WORDLIST must be placed into the GTPATH directory. This file contains a dictionary of words used to pre-compress the new (Q)uick bag format. DO NOT change this file in ANY way. To change this file will prevent the Q bags from being properly decoded on your system. 6. MDRIV now supports the use of **UNLISTED** in the NODELIST. This indicator may be placed on ANY node, however it is primarily intended for use with Independent Nodes and Independent Points (900 series node numbers). 7. MDIST has been modified to more gracefully handle damaged ARC or ZIP files. That is, if any damaged ARC or ZIP file is found, the following will occur: 1. The GBAG log will contain an ERROR message reporting the fact. So be sure that GBAG logging is enabled. 2. The damaged bag, either B, E or G, will be moved to the \MAILIN\PROBLEMS directory for your manual inspection and disposal. 8. MBAG and Independent Nodes MBAG will now recognize Independent Nodes and a sub-variation of that which we will call Independent Points. An Independent Point would have a different entry in the nodelist. An extra column would be added after the Sysop's name with the node number of a server for the point. Like this: 001/999 713-999-9999 24 Houston FIDO<->GT NGC Gateway Mel Douglass (001/010) Please notice that a column has been added, at the end of the line, which contains "(001/010)". 001/010 would be the Point Server for 001/999. What does this mean? First, MBAG will not consolidate netmail for any Independent Node (point or not) in the normal sense. For example, if you have the following routing statement in your routing file: ACCEPT 001/000-999 -> 022/000 MBAG will automatically convert this to: ACCEPT 001/000-899 -> 022/000 In other words, Independent Nodes will be restricted from the normal flow of netmail through the hub systems. This may be overridden, if need be, in much the same way as outlined above for MDRIVER, i.e. ACCEPT 001/000-899 -> 022/000 ACCEPT 001/900-999 -> 022/000 But, be aware, most hub systems will not welcome mail for Independent Nodes. If, however, the Independent Node happens to be a "point", then MBAG will automatically consolidate mail for the Independent Node in a G bag addressed to the Point Server. For example, in the case of 001/999 above any B bag for 001/999 would be placed, automatically, into a G bag for 001/010, the Point Server for that Independent Node. Not all Independent Nodes will have a Point Server, in which case they will be totally responsible for handling their own netmail. They will have to "drop the nickel", in most cases, to call and collect their mail, otherwise it will simply go stale. 9. The operator may use a /P option on the MDRIV command line to allow calls to be placed to Independent Nodes. The /P option would say, "It's okay to call 900 series nodes". /P ... Allow calls to be made to 900 series nodes. Normally, no call would be made to 900 series systems. Also, MDRIV will not forward netmail for Independent Nodes. For example: ACCEPT 004/000-999 -> 015/000 Would be converted automatically to: ACCEPT 004/000-899 -> 015/000 You may override this conversion, if you wish by placing the following lines in your routing: ACCEPT 004/000-899 -> 015/000 ACCEPT 004/900-999 -> 015/000 Please note that it is expected that most hub systems will not welcome such mail movement for Independent Nodes, so you should think carefully before overriding the default action. 10. Support for BIMODEM for netmail transfers. It is possible to specify a max baud rate for BiModem. By using these options on the MDRIV command line: /I Use BiModem. Not on PC Pursuit. No max baud rate. /I2400 Use BiModem. Not on PC Pursuit. At or below 2400 baud. /IP Use BiModem. Enable PC Pursuit. No max baud rate. /IP4800 Use BiModem. Enable PC Pursuit. At or below 4800 baud. The max baud rate may be any rate up to 9600. Over course, it is unlimited if not specified. I have added code, as directed by Erik Labs, to try and overcome problems reported with PC Pursuit. Using Zmodem we "set 5:1" on PC Pursuit, the new code will switch to "5:0" prior to invoking BIMODEM. I have reported problems with excessive error retries to Erik Labs. They have responded with v1.14 which will allow the sysop to specify the maximum number of error retries. PS: You will need to install the new BITX.BAT and GTBIMOD.EXE files to use the BiModem transfers during netmail. WARNING: You should be sure that BiModem is properly working and logging during regular host mode operations, before turning it on for use with netmail. And lastly, I encourage all of you who are going to use BiModem to register with John Erickson. He is not asking much, I believe his "Sysop Deal" is $10 and regular registration is $20 or $25 (not sure which). But this new protocol is a real winner, it is worthy of your support! 11. MDIST now supports up to 200 entries in MESSAGE DISTRIBUTION section of the routing file. 12. New GTBIMOD.EXE. A new version of GTBIMOD.EXE is being introduced to correct some bugs in the handling of time limits during netmail operation. 13. MBAG has been fixed so that it will not G bag items for a net/node that has a DX or FR outstanding. The reason for this is that if the DX or FR is bagged, then it will not take effect, especially if you are routing normally thru a 3rd party. 14. The /VG option has been added to MBAG and MDIST. This option will produce a verbose listing of the GCONSOL file onscreen (which was the previous normal action). Without the /VG option, the GCONSOL file will not be listed. 15. The /Tm:n option has been added to MDRIV. This option allows the user to specify the allowed maximum times in seconds to be connected to PC Pursuit and to still be allowed to redial on a BUSY. In other words, when the program is about to redial after a BUSY, it checks the current connect time against this limit, if the limit has been exceeded, then it will cease redialing and disconnect from PC Pursuit. I will refer to 'm' as the T1 time, which is measured from the very first CONNECT to the PCP modem in your local area to the time you are connected to the modem in the remote city. T2 is the time you are connected to the remote city. PCP has said that there will be a 60 seconds setup time allowance, I have taken that to mean that T1 must be kept under 60 seconds. The T1 time limit will default to 45 seconds, which means that MDRIV will not attempt to redial a remote city if T1 exceeds 45 seconds. PCP has said that there will be 90 seconds of no charge time once you are connected to the remote city, so T2 must be less than 90 seconds. T2 will default to 50 seconds, which means that MDRIV will not attempt to redial a BBS or NM system if T2 exceeds 50 seconds. The time limits are only checked prior to performing a redial operation, so if the result of the redial are slow coming back, the 60 second or 90 second limit could be exceeded. An example of setting these limits: /T45:50 This would be the same as the defaults. Also the logging has changed again to reflect these new limits: 08-05 20:22 PCP CONNECT HOUSTON 602 7B 08-05 20:22 PCP DISCONNECT T1=00:00:12 T2=00:01:03 TOT=00:01:16 This new format shows the time break down for T1, T2 and TOTAL. The T2 time probably matches the billed time as closely as I can tell. But if T1 exceeds 60 seconds, there may be extra billings made, I am not clear on how the 60 second setup allowance works with T1. 16. The new MBAG program corrects a problem which caused premature pruning of bags, before they could be included in G bags for retransmission. This showed up on systems which had a very small value on the MBAG command line for number of days to keep on-hand. Regards, Paul Meiners October 26, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netmail Version 200 3-19-89 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ********** IMPORTANT: The native mode of the new MBAGGER and MDIST program is ********** the format that will be required by the upcoming GT POWER 15.00 release. In order to use these programs with older version of GT POWER, you must use the /OC command line switch with these programs. MDRIVER is compatible with both formats without need for command line switches. A change in the way Zmodem file transfers are handled -if an non-zero return code is received by MDRIVER from the DSZ program, the received bags, if any, will be moved into a new directory, \MAILIN\PROBLEMS, and an entry will be made in the GTNET.LOG to document this action. The sysop should examine these bags, perhaps unpacking them manually or with a special run of MDIST. But please be prepared for these bags to be corrupted. In the past, MDRIVER simply erased these bags, but it seems that DSZ is not returning questionable error signals. New command line switches for MBAGGER: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /CF ... Suppress all .FR requests encountered during the bagging run. /CD ... Suppress all .DX requests encountered during the bagging run. /CA ... Suppress both .FR and .DX requests. As if you had both /CF and /CD on the command line at the same time. /Knn .. The 'nn' should be be a unique number between 1 and 65535. It is used with the .CY command to encrypt messages on your system. Please note, you should _NOT_ use te same /k number on the MBAGGER and MDIST command lines. Keep this number SECRET. /NL ... Suppress the new G bag logging from MBAGGER. If not present, MBAGGER will cause entries to be written to GBAG.LOG to document the creation/update of G bags. /NP ... This option causes the MBAGGER program to skip the pruning of echomail from \MAILOUT and is quite useful in speeding the operation of the program. The echomail need not be pruned more than once a day. /OC ... This option allows the MBAGGER program to be used with GT POWER 14.03 and before. The native mode of MBAGGER will be the GT POWER 15.00 mode. /X .... Bag mail in a normal fashion, but skip any echomail conference which is sponsored by the local sysop. This prevents problems with multiple baggings on the same day by echomail sponsors. The echomail sponsor would need at least 1 run per day without this option. /Zn ... Use PKZIP to pack bags. The 'n' is the level of compression desired. Valid values are 1..4. Care should be used to insure that the system you send bags to can handle ZIP the ZIP format. Also an explanation of the /Dxx switch. The /Dxx switch will remove old E bags and maintain the requested number of bags for active conference areas. For example, /D10 would maintain 10 =days= worth of back E bags. However, for inactive conferences, i.e. not currently listed in the MESSAGE DISTRIBUTION section, MBAGGER will leave all E bags to the disposition of the sysop. Another change, that is related to the /Dxx switch is a change to the MESSAGE DISTRIBUTION section. You can now specify an override for any particular conference. You can maintain more or less than is asked for by the /D switch with this option in the MESSAGE DISTRIBUTION section. There are actually two changes to the MESSAGE DISTRIBUTION format, the second change allows the inclusion of descriptions for the conferences, which will be included in any .GL report sent to subscribers. Here is the new format: MESSAGE DISTRIBUTION E00/001,5 -> D:\GT_ECHO , GT_Power_Echomail E00/005,10 -> C:\DOORS , Door_Echomail E00/009,5 -> C:\SOFTECH , Soft_Tech_Echomail E00/000,15 -> D:\BETA_ECO , ;Beta_Test_Echo (geewhiz) E00/019 -> C:\SYSOP , GT_Network_Sysop E10/009 -> skip , Shareware_Echo E00/043 -> C:\COOKBOOK , ;Cookbook_Echo END In this case, assuming the /D4 setting was in use, MBAGGER would keep 5 days of E00/001, 10 days of E00/005, 5 days of E00/009 and 4 days worth of E00/019 (/D4 = 4 days). This should give a good deal of flexibility in dealing with different conditions in different conferences. Also, note the "_" characters in the description field, these are changed to blanks by the netmail programs, as need be, since all other blanks are automatically removed. The description is limited to 20 characters, so be brief. Also, you may begin a description with a ";" to eliminate a sensitive conference from the .GL report. (So others need not know I like to cook! For example. <GRIN>) Also, please note in the example MESSAGE DISTRIBUTION above, the word "skip" is given as the pathname for the E10/009 conference. This means that the conference is not actually maintained on the system. That is, the sysop keeps the conference in \MAILOUT for others to get, but it is not bagged or distributed. Again referring to the MESSAGE DISTRIBUTION above, the line for E00/000 contains the word 'geewhiz' within (...). This indicates that this conference is garbled using this word. In order to read this conference you must have the password properly shown in the MESSAGE DISTRIBUTION. Both sponsor and subscriber use the same password. New command line switches for MDIST: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Knn .. The 'nn' should be a unique number between 1 and 65535. It is used with the .CY command to decrypt messages to your system. Please note, you should _NOT_ use the same /K number on the MDIST and MBAGGER command lines. Keep the number on your MBAGGER line secret, _but_ tell those, who wish to send encrypted messages to you, the number you have selected for use on your MDIST line (otherwise incoming messages may not be decrypted). /NA ... No Remote File Attach. This command causes any .RA received from a remote system to be discarded. A message will be returned to the sender explaining that the .RA was not authorized. /NR ... Causes the response to the .GL command to exclude a full list of available echomail conferences. Instead producing a report of the current status of the requestor's conferences only. /NL ... Causes MDIST to suppress keeping the new G bag log. This new log is now produced by default, and this switch can be used to suppress it. If the log is kept, a record of each G bag processed through MDIST and its contents will be kept in a file called GBAG.LOG. This file will grow indefinitely, it is up to the sysop to periodically archive it. MDIST will build a new one if an existing GBAG.LOG file is not found. /OC ... This option allows the MDIST program to be used with GT POWER 14.03 and before. The native mode of MDIST will be the GT POWER 15.00 mode. /SB ... Save B bags prior to unpacking and distributing to the message base. The bags are saved in MAILARC.ARC, which will be created in the \MAILIN directory. The sysop is responsible for pruning bags from this archive as required. /SG ... Save G bags prior to unpacking and distributing. Same as above for the /SB option. /SA ... Save both B and G bags prior to unpacking and distributing. Same as above for the /SB and /SG options. /V .... This option can be used when G bag logging is enabled (which is the default). The /V option causes verbose logging of G bags before they are unpacked. MDIST will invoke PKARC or PKZIP, as required, with the V option and append the output to the GBAG.LOG file. Thus providing a complete record of the files contained in the G bag. /Zn ... Use PKZIP to pack bags. The 'n' is the level of compression desired. Valid values are 1..4. This is used to select the storage method to be used with the /SB, /SG and /SA options listed above. Unpacking of ZIP format is handled automatically, the MDIST program will auto-sense ZIP vs ARC format bags. New command line switches for MDRIVER: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Bnn .. The 'nn' is the number of times you wish to try to connect to a remote city through PC Pursuit at 2400 baud (if available), before dropping down to 1200. This parameter only affects the dialing through PC Pursuit to a remote city (i.e. the Telenet "C D" command). /Lnn .. This option would cause MDRIVER to try each node only 'nn' times before removing it from the calling queue for the session. For example: /L3 This would cause the MDRIVER to try each node 3 times then giving up. The nodes will be dialed in the normal rotation, of course --this does not affect the order in which they are called. /NC ... This option would cause MDRIVER to take the crash call for long enough to get the caller's id, then disconnect. Effectively this is an option to say: NO CRASH CALLS AT THIS TIME. But it will update the GTNET.LOG file and show you the ID of the calling system. /NOW .. This can be placed on the command line where the start time is usually given. This insures that MDRIVER will begin immediately, no matter what the current time is. Of course, care must still be taken with the ending time, but the latest start time is now ignored (although it must still be stated). For example: New style: mdriv043 xxxx-yyyy /now 2459 2459 /cc /q /r:routing.cr2 /zc Old style: mdriv043 xxxx-yyyy 0100 2459 2459 /cc /q /r:routing.cr2 /zc /OW ... This option turns the CALL WINDOWS, described below, into a full scheduling mechanism. All inbounds/outbounds will be auto-generated to make the MDRIVER call the designated systems at the required time (all other calls will be automatically suppressed). The OW stands for "Outbound Windows". Since the /OW option generates inbound and outbound statements automatically, the node range option of the CALL WINDOWS should not be used. The program can become easily confused. WARNING: DO NOT use the option unless you are using CALL WINDOWS. Extra outbound calls will be placed if this command is used in the absence of CALL WINDOWS. /Q:x .. This is an old option with a new twist. The /Q continues to mean that the MDRIVER will quit after placing all calls. But now you may specify a particular node that is to be called. The 'x' has the format 'net-node'. For example: /Q:009-000 This would force a call to 009/000, then exit from the program. /Q009000 This is the same as above. The punctuation is for readability only, and may be omitted by the user. /Q This would allow MDRIVER to follow the routing instructions, and quit after all calls have completed. New dot commands for messages: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .CC ... An internal system command, used by the system to garble netmail messages. Should not be directly used by individuals. .CY ... Encrypt the information on the line following. This information will be returned to normal on the receiving system. .CS ... Acts like a continuous run of .CY commands. For example if you wanted to encrypt an entire paragraph or message. Like this: .CStart These lines will be encrypted. This is the second line to be encrypted. .CStop The two lines shown between the .CStart and .CStop will be encrypted. The .CS command works with the .KE command in the same way that the .CY command does, with the extra attraction that the .KE command may itself be encrypted. Like this: .CSstart .KE 8123 All lines between the .CStart and .CStop are encrypted. This is another line encrypted. .CStop This just adds one more level of protection to sensitive data. ******** WARNING: The encryption feature described herein provides a very low level ******** of protection. It is meant only to keep the curious from reading your mail. DO NOT rely on it for any substantial purpose. P&M disclaims the responsibility for any loss incurred due to the use of this encryption scheme. .EC ... An internal system command, used by the system to garble echomail conferences. Should not be directly used by individuals. .KE ... This command affects the encryption process done by .CY and .CS so that it is less likely that outsiders will be able to unsramble the information. The .KE is followed by a number between 1 and 65535, which must match the /K number on the receivers MDIST command line. For example: If the receiver told you ahead of time that his code number was /k8123 on his MDIST command line, then you would code this in your message: .KE 8123 .CY .CY This is an encrypted message, that can be read by .CY a system with /k8123 on the MDIST command line. .CY Then the receiving system should have: MDIST /r:routing.bbs /k8123 ******** WARNING: The change described below to the .FA is dangerous if you have ******** granted the FR permission on a CLASS card in your GTPASSWD.BBS file to anyone other than the Sysop. Potentially, a caller could take any file on your system. The best policy would be to restrict the FR option to only full Sysop level people. .FA ... The .FA or file attach command is not new, but there has been a slight change. The .FA command will now accept a path other than the \MAILOUT\FILEOUT directory. For example: .FA foo.bar Would pick-up FOO.BAR from the \MAILOUT\FILEOUT directory. .FA \lotus\spread.wks Would pick-up SPREAD.WKS from the \LOTUS directory. ******** WARNING: The use of the .Gx commands is probably incompatible with ******** the software provided by other authors. If the sytem you are sending .Gx commands to is not using compatible software, these commands will not work properly. .GL ... If this command is placed in a netmail message to a system which is sending you a G bag, that system will respond with a report of the current status of the conferences you are receiving and, if authorized, a list of conferences available on that remote system. Example: .GL Where the "." is located in the first position of the line. .GM ... If this command is placed in a netmail message to a system which is sending you a G bag, it will allow you to add conferences or modify the day number that you are receiving in a currently received conference. Example: .GM e00/001,810 Again, where the "." would be located in the first position of the line. The GM is followed by a single space and the echo conference number you wish to add/modify, followed by the new or starting day number. .GQ ... If this command is placed in a netmail message to a system which is sending you a G bag, it will allow you to drop a conference from the G bag you are receiving. Example: .GQ e00/001 As above, the "." should be located in the first position of the line. The GQ is followed by a single space and the echo conference number you wish to remove. .MA ... This command is much like the .FA command. It will also accept full pathname specification or default to the \MAILOUT\FILEOUT directory, when no pathname is given. It will take the named file and create a message to be sent with the "cover message". The attached message will be given the same security level as the "cover message". One caveat exists, that is the attached message must be an ASCII text file, the first line of which has the following: MSG ATTACH. If the message does not contain the MSG ATTACH header, then the file will not be attached. This provision is made, so that the sysop will have control over which ASCII files are attachable in this manner. For example: .MA c:\wp\text.dat .RA ... This is a Remote File Attach. The command works much like a FR (File Request) command, except that it works through normal network channels, causing the receiving system to generate a FA for the requested file. Only files located in the \MAILOUT\FILEOUT directory can be obtained in this manner, as pathnames are not supported with this command. For example: .RA foobar.dat Would generate the following on the host system: .FA foobar.dat And automatically send the message and attached file back to the original requestor. .RR ... This is the Return Receipt Request. The receiving system will respond with a message confirming receipt of the message containing the .RR command. The Return Receipt should be in the following form: ~CS The following message was received at: 009/000 ============================================== Msg No : 2021 Date : 3-13-89 Time : 20:50 Sender : Paul Meiners Topic : NOTHING IMPORTANT Prepared By The MDIST Program: 3-13-89 22:10 ~CS .ORIGIN: 009/000 - the Programmer's Workshop -West! Note the usage of .CS encryption to help insure accuracy. The message number is the number of the original message on the sending system (the one with the .RR command). .RV ... An internal system command, used by the system to provide 'return receipts' associated with the .RR command. Should not be directly used by individuals. With the advent of the .Gx commands, the treatment of the GCONSOL.CTL file and the BAG CONSOLIDATION section of the routing file will change. In the past, the BAG CONSOLIDATION section was in control. Now the GCONSOL.CTL will control, and it will be maintained by the requestor via .Gx commands. The BAG CONSOLIDATION section will still have a role to play however, in that no system will be able to get G bags from the host system unless an authorizing entry appears in the curren BAG CONSOLIDATION section (it will act as the trigger). Once triggered tho, the requesting (or subscribing system) will be able to control the content of the G bag without the intervention of the host sysop. A sample .GL report: An Echomail Status Report For The Sysop Of 009/000: Conferences available on 001/033: (√) = in G bag! ================================= √ E00/001,0776 - GT POWER ECHOMAIL E00/005 - DOOR ECHOMAIL √ E00/033,0776 - SYSOP TOOLS ECHO √ E00/043,0774 - COOKBOOK ECHO Conferences coming to you in G bags from 001/033: ================================================= E00/001,0776 E00/005,0776 E00/033,0776 E00/043,0774 Prepared By The MDIST Program: 2-15-89 18:04 To further support the use of the ZIP format, a change is being made to the BAG CONSOLIDATION section. Flags are being added to the node entries in this section, as follows: Z ... Use PKZIP to build G bags for the indicated node. F ... An override for the ';' in the MESSAGE DISTRIBUTION allows the indicated node to receive a full .GL report when requested. For example: BAG CONSOLIDATION 001/032,ZF E00/001,760 009/000,Z E00/001,760 E10/000,760 001/003 E00/001 END Please note that the flags are separated from the node number by a comma. The order of the flags is optional. And flags are _not_ specified for individual conferences, but only for regular nodes. In this example, 001/032 would be allowed a complete .GL report, overriding any ';' inhibitors in the MESSAGE DISTRIBUTION section, and G bags for him would be created with the PKZIP program. Also in the example, 009/000 would not be given an override for the .GL report, but would have G bags created with the PKZIP program. Finally, 001/003 would have no override granted and would get normal ARC style G bags. In support of scheduled outbound calls (the system has been rather ad hoc), a new section of the routing file is being introduced: CALL WINDOWS. The MDRIVER program will support up to 40 call windows, which will act as a way to limit the times that particular systems are called. Please note that the call windows do NOT replace outbound statements, i.e. if you aren't calling a system, the call window will NOT cause a call to be placed. Here is the way it should look: CALL WINDOWS 001/032,1:00-2:00 009/000-999,4:00-4:45 END Please note that the node range is optional (and should not be used with the /OW command line switch), but a complete time range must be specified. While a call window is present in the routing file, the listed systems will only be called during the designated hours (assuming that a call is triggered by an outbound statement, the presence of mail or the /Q:x command line option. It is permissible to have multiple windows per node. The format of the GTNET.LOG file has changed slightly. The total connect time is now included on the DISCONNECT entry. Like this: 02-27 18:25 CONNECT 2400 WITH 009/000 CRASH! 02-27 18:25 HOST ID: 009/000. PROG ID: 044 02-27 18:25 RECV MAIL. 02-27 18:26 DISCONNECT 00:00:50 -------- New Regards, Paul Meiners February 27, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netmail Version 193 2-4-89 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This version is released very quickly after 192, not to fix a bug, but to supply a asked for feature (that I had forgotten). Sorry about that! A new option has been added to the MBAGGER to allow the bagging of messages which do NOT have the case of the ORIGIN line automatically forced to uppercase. The /L option on the command line will cause the MBAGGER to use the NAME= entry from the SCHEDULE.BBS file in the ORIGIN line of the message without converting it to uppercase. Regards, Paul Meiners February 4, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netmail Version 192 2-1-89 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This version (and version 191 before it) is a bug fix release. It addresses a minor problem in the MDIST program and a problem with repeated baggings of netmail while G bagging is in use. Hopefully, these versions are now stable. Regards, Paul Meiners February 1, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netmail Version 190 12-8-88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o Routing Comment Entries. To ease the editing of routing files, the netmail suite of programs will now recognize a comment line in the routing. Any line that begins with a ";" character (the semi-colon) will be ignored. This is extremely useful when making temporary edits to INBOUND and OUTBOUND sections, but may be of use any place in a routing file. o Bag Consolidation. There are several changes brought about by BAG CONSOLIDATION. The first of which is a new section in the ROUTING.BBS file. An example follows: BAG CONSOLIDATION 001/003 E05/000,694 E00/001,695 E00/043,693 001/001 001/008 E00/001,696 E00/043,694 END The nodes to be consolidated are listed, with the desired echomail conferences (if any) following. The echomail listing is given followed by a comma to indicate the highest Julian date that that node has previously received (before being consolidated). Once an echomail conference has been consolidated the system will maintain this info in a file in the \MAILOUT directory called GCONSOL.CTL. At the current time, any one system may consolidate up to 2,000 echomail conferences (I hope they have plenty of disk space). Usually, the GCONSOL.CTL file will be automatically maintained, but from time to time it may be necessary to clear dead wood, change the value of Julian dates, provide listings --- these chores will be handled by MEDIT, a companion program written by Chris Smith, the author of SYSOP TOOLS. Thanks for the support Chris! It should be stressed that the listing of echomail conferences in this manner should only be done at the request of the receiving system and effects the flow of E bags to downstream nodes, i.e. you do _not_ consolidate E bags to be sent back up the echo-chain. YOU DO NOT DO THAT. To assist this new operation, each of the netmail programs has added the /G command line switch. It means something slightly different for each processor. As follows: MBAGGER /G /R:foox.bar This command would not bag mail! Instead it would only analyze existing mailbags to see if any consolidations can be performed. MDIST /G /R:fooy.bar This command would not distribute mail to the GT POWER message areas! Instead it will examine all consolidated bags that have been received addressed to the local node and break them down into their component parts. MDRIVER xxxx-yyyy ... /G ... This command would cause the MDRIVER program to SHELL to a special batch file at the end of any call during which the local system has received a consolidated bag. The name of the special batch file is G_UNPAK.BAT. A sample follows: MDIST /R:r0100.bbs /G MBAGGER /R:routing.cr1 /G This would cause any consolidated bag received during a session to be immediately broken down and re-consolidated in the indicated manner (by the routing and bag consolid- ation instructions). A word about how bag consolidation works. First the routing instructions are examined to see if mail bags are being routed through a common system and consolidation has been requested for that common system. These bags are then placed into a consolidation bag, without having been unpacked (bags within bags). Then the BAG CONSOLIDATION instructions are examined to see if any echomail conferences are to be included (they need not be included). If echomail conferences are included, care is taken to insure that old 'E' bags are not included - information for this purpose is recorded in the GCONSOL.CTL file (so don't erase it). Once all consolidations are performed, the resulting consolidated bags may be consolidated into themselves (if a common routing is discovered for consolidated bags). Please note that the B bags in echo conferences are consolidated based on the indicated routing, NOT on the listing of echo conferences in the BAG CONSOLIDATION section. In plain English, the B bags for an echo conference are treated like ordinary netmail and the BAG CONSOLIDATION listing of echo conferences only effects the handling of E bags (those that [E]cho from a sponsor's system). For example: ACCEPT 001/008 -> 001/003 ACCEPT 001/001 -> 001/003 ACCEPT E00/001 -> 001/003 BAG CONSOLIDATION 001/003 E00/049 E00/043 001/008 E00/001 E00/043 END Assuming mail is present for 001/001, 001/003, and 001/008, two consolidated bags would be created, one for 001/003 and one for 001/008, then since 001/008 is routed through 001/003, the consolidated bag for 001/008 will be put inside the bag for 001/003. The final result will be 1 bag for 001/003. When 001/003 receives this bag, that system will discover the consolidated bag for 001/008 and will forward it as directed by its own routing instructions. Consolidated bags are very much the same in appearance as ordinary B bags. Except that they are named with G as the first letter. And there will be G1 and G2 bags created, in the same manner as the B1 and B2 bags. These backup bags should be removed on a routine basis, to prevent un-needed clutter. o There are two new command line options for use with MDRIVER. As follows: /NL ....... Do not answer incoming calls. Assumes sysop is present and will not continue normal operation after a RING is detected, until sysop hits the <CR> key. /NR ....... Do not answer incoming calls. Assumes sysop is _not_ present and _will_ continue normal operation after a 30 second pause. No keystroke is required to restart operation. These options are useful if you wish to make a outgoing crash mail call from a phone normally used for voice operations. Please note that these options should _not_ be used on your regular data line, since they will interfere with the normal handling of incoming calls. o 2400 baud support for PC Pursuit: MDRIV039 is the first version of the mail driver to support 2400 baud on the PC Pursuit service. The first thing that everyone must understand is that not all cities have 2400 baud outbound access and not all cities have 2400 baud inbound access. So, we must be able to mix and match these items. There must be a way to control the different access numbers and the different city characteristics. Please note the new format: PURSUIT ACCESS/12=227-1018 ACCESS/24=227-8208 USERID=xxxxxxxx PASSWORD=yyyyyyyy CITIES 201,NJNEW/12-Newark 216,OHCLE/12-Cleveland 202,DCWAS/24-Washington 305,FLMIA/12-Miami 206,WASEA/12-Seattle 408,CASJO/12-San_Jose 212,NYNYO/24-New_York 718,NYNYO/24+New_York 414,WIMIL/12-Milwaukee 213,CALAN/12-Los_Angeles 503,ORPOR/12-Portland 214,TXDAL/24-Dallas END First, the syntax of the ACCESS entry has changed. The word ACCESS is now followed by either "/12" or "/24", to identify that number as to the indicated baud rate supported. Then in the table of cities, please note that each city code is also followed by a "/12" or "/24" to indicate if the city has 2400 inbound capabilities. Each city must have this annotation added, as appropriate. o New log entries. To help with debugging Telenet problems a new entry in the GTNET.LOG file will identify the Telenet terminal you are connected to. For example, the following would appear in your log: CONNECTED VIA PCP TO CLEVELAND 713 18Q Where "713 18Q" is the id for the Telenet terminal you are locally connected to. Also, for the sake of easier debugging by the programmer, the log will now show the version number of the MDRIVER in use. This will be displayed on the START OF SESSION line like this: START OF NETMAIL SESSION - 039 Regards, Paul Meiners December 8, 1988 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netmail Version 180 11-4-88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This version of the netmail software is introduces a new Echomail CRC mechanism for sponsors of Echomail Conferences. If you are the sponsor of an Echomail Conference YOU MUST GET NEW CRC's for your conference. The new CRC mechanism will insure that only the authorized net/node will be able to sponsor the indicated Echomail Conference. This change should not effect anyone, except for the sponsors of Echomail Conferences. This release also includes some minor bug fixes in the area of the Fixed DTE handling and the Destination Reporting. Regards, Paul Meiners November 4, 1988 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netmail Version 150 10-18-88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ o New command line paramters, MDRIVER: /Mn ..... Limits outgoing calls so that they will not "fallback" below this lower limit. The 'n' is the lowest baud rate that may be used in a "fallback" situation. For example: /M2400 would limit "fallbacks" so that they would not go below 2400 baud. /ZC ..... Enables the use of the Zmodem protocol through DSZ.COM. /ZE ..... Enables the use of the Zmodem protocol through DSZ.EXE. If you are enabling either DSZ, then the version selected, either EXE or COM, must be available in the GT POWER home directory. For example, if you have: set GTPATH=C:\GT Then DSZ must be located in the C:\GT directory. It is not invoked via a "shell" or a batch file, but for the sake of security and speed, it is executed directly from MDRIVER as a "child" process. This allows a very close coorperation between the two programs. But the result is that the normal ZM??.BAT batch files cannot be used, nor is the regular DOS PATH searched to find DSZ. o CRASH! Mail Feature: A new feature. CRASH! Mail allows the netmail software to run in a nearly ad hoc fashion. Picking up and delivering E-Mail at virtually any time. To enable CRASH! Mail, the nodelist must be updated to reflect which systems are "crashable". This is done by placing an '*' before the system name. For example: 001/001 713-772-2090 24 Houston PROGRAMMERS WORKSHOP Paul Meiners 001/002 713-664-7679 24 Houston PRIVATE SECTOR ...... Chris Smith 001/003 713-778-9471 96 Houston *P&M TEST SYSTEM ..... Paul Meiners 001/007 713-799-5545 24 Houston JOSHUA TREE ......... Larry Rushing Under CRASH! Mail, the GT POWER Host Mode will identify incoming netmail calls and pass control to the GTCRASH.BAT file, which the SYSOP must prepare to accept CRASH! Mail calls, using instructions provided in the Netmail Beta Documentation. Under the CRASH! Mail concept, incoming netmail can be handled on an ad hoc basis. But outgoing calls must continue to be scheduled. Outgoing CRASH! Mail calls may be scheduled at virtually any time (assuming that the destination is capable of Crash Mail). The DOOR.EXE program must be available, as described above, for GTCRASH.BAT to be properly invoked. PLEASE NOTE: The DOOR.EXE program is part of the upcoming GT POWER 14.03 release. With this netmail code, you will be able to make outgoing CRASH! Mail calls, to systems that are running the beta test version of 14.03. No system will be able to accept CRASH! Mail unless they are using release 14.03 or later of GT POWER. o New command line options for MDRIVER to handle CRASH! Mail: /CC ..... Make outgoing CRASH! Mail calls. /CA%3 ... Answer incoming CRASH! Mail call. This should only be used in the GTCRASH.BAT file, which is automatically invoked by the GT POWER host when an incoming CRASH! Mail call is received. This option will only be usable when GT POWER 14.03 is released. The "Crash Answer" command line switch must be followed by "%3", so that the GT POWER Host can pass the baud rate to the MDRIVER program. This option should only be used within the GTCRASH.BAT batch file. After an incoming CRASH! Mail call is finished, MDRIVER will automatically release control and allow the reloading of the GT POWER Host. An example of a GTCRASH.BAT file is shown below: c: cd \gt mdriv033 9999-9999 /CA%3 /ZE mdist o Other changes in netmail software: This beginnings of support for "Fixed DTE" are being introduced to MDRIVER. This accords greater support for high speed modems, such as the USR Courier HST and others. The netmail programs are being expanded so that a system may have up to 100 echomail conferences listed in the MESSAGE DISTRIBUTION section, up from 50 conferences in the previous release. Chuck Forsberg has been approached about the use of DSZ with the netmail programs. He has agreed to let this take place, however both Chuck and I encourage you to register DSZ if you are going to use it. It is the right thing to do, so send the man some money. He deserves it for the great product and the great support he gives to it. Regards, Paul Meiners October 18, 1988